Design verification is the process of determining whether an integrated circuit, board, or system-level architecture, exactly implements the requirements defined by the specification of the architecture for that device. Design verification for a device under testing (DUT) may be performed on the actual device, or on a simulation model of the device. For the purposes of explanation only and without intending to be limiting in any way, the following discussion centers upon testing which is performed on simulation models of the device.
As designs for different types of devices and device architectures become more complex, the likelihood of design errors increases. However, design verification also becomes more difficult and time consuming, as the simulation models of the design of the device also become more complex to prepare and to test.
The problem of design verification is compounded by the lack of widely generalizable tools which are useful for the verification and testing of a wide variety of devices and device architectures. Typical background art verification methods have often been restricted to a particular device having a specific design, such that the steps of preparing and implementing such verification methods for the simulation model must be performed for each new device.
The process of verifying a design through a simulation model of the device is aided by the availability of hardware description languages such as Verilog and VHDL. These languages are designed to describe hardware at higher levels of abstraction than gates or transistors. The resultant simulated model of the device can receive input stimuli in the form of test vectors, which are a string of binary digits applied to the input of a circuit. The simulated model then produces results, which are checked against the expected results for the particular design of the device. However, these languages are typically not designed for actual verification. Therefore, the verification engineer must write additional programming code in order to interface with the models described by these hardware description languages in order to perform design verification of the device.
Examples of testing environments include static and dynamic testing environments. A static testing environment drives pre-computed test vectors into the simulation model of the DUT and/or examines the results after operation of the simulation model. In addition, if the static testing environment is used to examine the results which are output from the simulation model, then errors in the test are not detected until after the test is finished. As a result, the internal state of the device at the point of error may not be determinable, requiring the simulation to be operated again in order to determine such internal states. This procedure consumes simulation cycles, and can require the expenditure of considerable time, especially during long tests.
A more useful and efficient type of testing is a dynamic testing environment. For this type of environment, a set of programming instructions is written to generate the test vectors in concurrence with the simulation of the model of the DUT and while potentially being controlled by the state feedback of the simulated device. This procedure enables directed random generation to be performed and to be sensitive to effects uncovered during the test itself on the state of the simulation model of the device. Thus, dynamic test generation clearly has many advantages for design verification.
Within the area of testing environments, both static and dynamic testing environments can be implemented only with fixed-vector or pre-generation input. However, a more powerful and more sophisticated implementation uses test generation to produce input stimuli.
One example of such a test generator is disclosed in U.S. Pat. No. 6,182,258, incorporated by reference as if fully set forth herein. This test generation procedure interacts with, and sits as a higher level over, such hardware description languages as Verilog and VHDL. The test generation procedure is written in a hardware-oriented verification specific object-oriented programming language. This language is used to write various tests, which are then used to automatically create a device verification test by a test generator module. A wide variety of design environments can be tested and verified with this language. Thus, the disclosed procedure is generalizable, yet is also simple to program and to debug by the engineer.
The disclosed language features a number of elements such as structs for more richly and efficiently describing the design of the device to be simulated by the model. Unfortunately, the disclosed language and resultant test generation environment does not include the ability to use bitwise constraints.
A bitwise constraint can also be termed a “bit slice constraint”. In the modeling of hardware entities such as registers, and input data such as computer instruction streams, there is often a need to express a property over some partial segment of the variable. An example would be a computer instruction word that is 32 bits wide composed of an opcode field of 16 bits and an operand field of 16 bits, where the desired property is to keep the operand field to the value of zero.
U.S. patent application Ser. No. 09/020,792, described above, discloses a method of applying arithmetic constraints which consider the value of the variable as a whole, or the full 32 bits in the example above. Bitwise constraints add the ability to constrain arbitrary sub-fields of a variable and perform bitwise operations on the variable. Bitwise constraints can be defined as arithmetic relations where at least one of the following bit operations is used:    [:] (slice)    | (bitwise or)    & (bitwise and)    ^ (bitwise exclusive or)    ˜ (bitwise negation)    << (shift left)    >> (shift right)
One example of such a bitwise constraint is the expression:keep x[2:0]==0b101Currently available code languages for test generation would compute the operator “[:]” as a function, such that in the above example, an unconstrained x variable would first be generated. Next, “x[2:0]” would be computed as a function, after which the value for this computed function would be compared to “0b101”. Such a process would frequently result in an incorrect calculation, and hence an incorrect constraint. A more usefull solution would handle such a bitwise constraint correctly through more flexible generation. Unfortunately, such a solution is not currently available.